Over the past few years, coverage-guided fuzzing has become a popular way to
find software and hardware vulnerabilities due to advances in publicly
available tools such as \AFL{}\cite{afl} and its derivatives.\cite{vanhauser} Many
fuzzers have ``trophy cases'' consisting of a list of bugs known to be found with that tool to
demonstrate their effectiveness against real-world applications.\cite{rustfuzztrophy}\cite{honggfuzz}\cite{afl}  However, most
tools are primarily focused on finding bugs in open source, command line Linux
software which reads input from files or standard input. While there has been some
exploration to get \AFL{} working on other operating
systems\cite{aflosx,winafl} as well as supporting network
input,\cite{netafl,preeny} these features are often omitted.

Most of the published improvements over the original version of \AFL{} are
implemented as forks of
\AFL{}.\cite{aflfast,aflgo,fairfuzz,perffuzz,pythia,collafl}
Thus the enhancements are mutually exclusive, short of embarking on a
development effort to review the modifications and merge the forks back
together, manually resolving any conflicts and incompatibilities.  The issue
of incompatibility is not limited to projects which are modified versions of
\AFL{}. Mixing and matching features from various tools requires a significant
amount of effort. It involves setting up a build environment, which in itself
can be a challenge, as well as merging together different code bases.  Often
times the code bases will be written in different programming languages, which
means they need to be integrated in some way.
Using a tool against a type of software it has never been
used against before, such as using a Linux kernel fuzzer against another
operating system, can find a large number of bugs\cite{anton}.  However, in practice, security
professionals rarely have the amount of time to invest to get the tools working
together, or working in other contexts.

We present Killerbeez, a fuzzing framework which brings together many of the
various security analysis tools so they can be used together.  Killerbeez
supports multiple operating systems, can handle target applications with or
without source code, and software with a \GUI{}.
Furthermore, the input mutation algorithms, instrumentation, seed selection
algorithms, and methods for feeding input data to the target are all easily
interchangeable via modular components.  This modularity enables two
properties (1) easily mixing and matching
tactics from different researchers and (2) implementing new algorithms easily.
Finally, Killerbeez is scalable, using \BOINC{}\cite{boinc} to distribute work
to multiple nodes from a central server.

Our contributions include:
\begin{enumerate}[noitemsep]
\item An \API{} combining the different components of a fuzzer in a pluggable (modular) way to allow for extensibility
\item A collection of existing fuzzers modified to use the \API{}
\item A method for automatically determining which libraries are likely to
	cause a crash, so those can be targeted while fuzzing
\item A technique for quickly utilizing \IPT{} trace information to identify unique code traces while fuzzing
\item Ability to automatically filter out trace data related to non-deterministic code
\end{enumerate}

Section \ref{Background} covers background information, section
\ref{Killerbeez Overview} provides an overview, the implementation is covered
in section \ref{Implementation}, and sections \ref{Related Work},
\ref{Future Work} and \ref{Conclusion} cover related work, future, work and
conclusion, respectively.
